为什么还要写一个PHP框架？

背景

事情源于在做框架选型的时候，我们对业务需要的技术栈进行了分析，发现我们需要的框架只需要包含路由、数据库、Redis、日志，就可以满足需求了，大家讨论后开始着手框架的选择。

选型

讨论框架选型时部分人意见偏向使用Laravel、Yii这种富功能框架，这些框架提供的功能是完全可以满足业务需求的，然而反对的意见则是这些框架的学习成本比较高，新人接手不容易，而且性能较差，很多特性都用不到；而另一部分人则偏向于使用Slim、Yaf, 框架提供了基本的路由，其他功能组件则通过lib加载进来，这样就可以按需加载各种功能组件，没有多余的feature，学习成本相对较小，同样这种方案也有很多反对意见，各个组件是否能与框架结合的很好，每个lib有各自的API风格，学习成本也不小，而且如何保障各个lib的稳定性。

在这样的情况下，就有了构件一个满足各方需求框架的想法，团队希望框架只包含了常用的功能组件，像Event、Behavior、Broadcasting、Notification这些很少用到的功能尽量不需要，减少不必要的学习成本；为了支持一些业务千万级的PV，希望框架的性能足够好；同时希望框架的可维护性较好，针对一些特殊的场景，框架能提供良好的扩展能力，将一些功能集成到框架里。

最后讨论决定自己开发一个框架，于是就开始了整体框架的设计。

设计

框架

首先是底层框架，设计底层框架的第一个问题就是如何管理框架的所有类及其依赖关系，对比成熟的方案有依赖注入和基于组件设计两种方案。由于考虑后续需要对各个组件进行单元测试，选择了依赖注入的方案。

功能组件

第二个就是框架的核心组件，框架包含的基本功能组件有数据库、验证、日志、Session、Cookie、Redis等，封装这些组件有两种方案，可以采用外部开源的composer组件，或者自己实现，由于不同composer库API风格不一致，而且很多库require文件太多，决定这些核心组件均自己实现。

易用性

要完成一件事，很多富功能框架提供了多种方式，在开发一个功能时，既可以使用A方法，又可以使用B方法，有时用户可能很迷惑，到底应该用哪个呢；而且随着业务迭代，到处是各种异同的使用方式。所以我们偏向于只提供单一的方式，减少用户选择的困惑，同时提供系统的可维护性。

扩展

框架包含了常用的基础组件，为了支持使用一些特殊的组件，框架集成了composer，并且提供了基于组件的扩展能力。

总结

最后，经过三个多月开发，框架开发完成，并且已经成熟在几个产品使用；框架的有些地方可能还需要不断优化，也欢迎大家提及各种Issue，我们的目标是打造一款国内、优秀的PHP框架。

最后直接列一下框架以及开发手册。：）

BetePHP: https://github.com/betephp/be...
中文手册: http://betephp.com/zh/